Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Vite doesn't inline SVG assets #1197

Closed
andylizi opened this issue Dec 3, 2020 · 6 comments
Closed

Vite doesn't inline SVG assets #1197

andylizi opened this issue Dec 3, 2020 · 6 comments

Comments

@andylizi
Copy link
Contributor

andylizi commented Dec 3, 2020

vite/src/node/build/buildPluginAsset.ts

Lines 60 to 63 in 480367b

if (!id.endsWith(`.svg`) && content.length < Number(inlineLimit)) {
url = `data:${mime.lookup(id)};base64,${content.toString('base64')}`
content = undefined
}

Hi. I noticed that svg files is explicitly excluded in the assetsInlineLimit feature, and I'm wondering why that is so. Renaming the extension to .SVG (thus bypassing the .endsWith check) works fine in my project.

This limit exists since the first time the feature was added, and I'm unable to find any kind of comments or documentation about it. Could someone shed some light on this please? Thanks!
@underfin
Copy link
Member

underfin commented Dec 4, 2020

Look like !id.endsWith(.svg) should be removed.. @antfu @aleclarson what do you think?

@aleclarson
Copy link
Member

aleclarson commented Dec 4, 2020 •
edited
Loading

We don't want to use base64 with svg files. See here: https://css-tricks.com/probably-dont-base64-svg/

Basically, base64 is larger in size, and svg files don't need it to be inlined. In fact, svg files even compress better without base64, because there's more repetition.

If svg files aren't inlined currently, they should be. Just without base64.

@underfin
Copy link
Member

underfin commented Dec 5, 2020

@aleclarson Thanks for yor clarify.

@underfin underfin closed this as completed Dec 5, 2020
@andylizi
Copy link
Contributor Author

andylizi commented Dec 5, 2020

Are there plans to support inlining svg without base64?

@underfin
Copy link
Member

underfin commented Dec 5, 2020 •
edited
Loading

Are there plans to support inlining svg without base64?

Can you open a new issus to discuss it?

@andylizi andylizi mentioned this issue Dec 5, 2020
Closed
aleclarson referenced this issue in aleclarson/vite Jan 25, 2021
@aleclarson
feat: allow .svg files to be inlined
56e98b3 
Base64 is unnecessary for SVG files:
https://github.com/vitejs/vite/issues/1197\#issuecomment-738780169

Also using `Buffer.byteLength` instead of character length when comparing with the `assetsInlineLimit` option.
aleclarson referenced this issue in aleclarson/vite Jan 25, 2021
@aleclarson
feat: allow .svg files to be inlined
1ea1c84 
Base64 is unnecessary for SVG files:
https://github.com/vitejs/vite/issues/1197\#issuecomment-738780169

Also using `Buffer.byteLength` instead of character length when comparing with the `assetsInlineLimit` option.
@aleclarson aleclarson mentioned this issue Jan 25, 2021
Closed
@princed princed mentioned this issue Apr 8, 2021
Closed
@polarathene
Copy link

Basically, base64 is larger in size, and svg files don't need it to be inlined. In fact, svg files even compress better without base64, because there's more repetition.

"compress better without base64", everything does.... base64 is an encoding useful for content like binary which can't be represented in ASCII/UTF-8 text content, but has a drawback of 6 bits for every 8-bits, roughly 1.33x increase in weight.

Inlining content via a base64 data URI still has it's benefits despite this.

What you're referring to is inline SVG element, which isn't always appropriate (eg favicon).

In some cases you need more accurate / crisp rendering and need the SVG content to be the src of an <img> element instead. As img is a replaced element, it has some drawbacks vs inlining SVG into the DOM, however if you're scaling the content, it will be properly buffered into pixel width/height even if it'd otherwise be a floating point value. I've had this with logos that involve some vectorized text which suffer aliasing issues at certain scales on low DPI displays as there is no shape hinting.

You can workaround that by providing an integer width/height, but you must know that in advance and it comes with some other disadvantages if you want responsive content. Additionally the img element allows providing the alt attribute which has value beyond screen readers (more so if the file isn't inlined/embedded but remains an external file reference).

@github-actions github-actions bot locked and limited conversation to collaborators Jul 16, 2021
@vitejs vitejs unlocked this conversation Nov 11, 2021
@aleclarson aleclarson reopened this Nov 11, 2021
@vitejs vitejs locked and limited conversation to collaborators Nov 11, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@aleclarson @polarathene @andylizi @underfin